Security-JAWS 第26回レポート #secjaws #secjaws26 #jawsug

こんにちは、臼田です。

Security JAWS 第26回が開催されましたのでレポート致します。

Security-JAWS【第26回】 勉強会 2022年8月25日(木) - Security-JAWS | Doorkeeper

動画

レポート

告知

• AWS Startup Community Conference 2022やるよ！
• JAWS DAYS 2022 - Satellite -やるよ！

Session1: アクセスキー運用管理のベストプラクティス アマゾン ウェブ サービス ジャパン合同会社 Security Specialist Technical Account Manager 飯島 卓也さん

• AWSサービスに対してプログラムによるアクセスをする場合にはアクセスキーを利用する
  • 不正アクセスや不正利用などを防ぐためにアクセスキーの管理が大切
• アクセスキーの概要
  • アクセスキーはアクセスキーIDとシークレットアクセスキーの2つから構成される
  • IAMユーザーに対して作成したアクセスキーは永続的に有効な認証情報
• アクセスキー運用管理における検討項目
  • NIST CSFの観点での対策をまとめた
  • 識別
    • アクセスキーの管理と使用状況の把握
  • 防御
    • 漏洩させないための対策
  • 検知
    • アクセスキーの監査
      • ポリシー通りになっているか
    • 脅威検知
  • 対応
    • どう対処していくか
• アクセスキーの管理と使用状況の把握
  • 認証情報レポートを使用したアクセスキーの管理
    • IAMのコンソールから認証情報レポートページでCSVをダウンロードできる
    • IAMユーザーの一覧と対応するアクセスキーの一覧
    • アクセスキーがアクティブか、ローテーションされたのがいつか、最後に使用したのはいつかなどわかる
    • これを確認して棚卸しをする
• アクセスキーの漏洩対策
  • ルートユーザーのアクセスキーを作成しない
  • IAMユーザーのアクセスキーは原則作成しない(不要なアクセスキーは削除する)
    • SCPによる作成防止
  • APIが必要なら一時的な認証情報を利用する
    • IAMロール
    • IAM Roles Anywhereの利用
    • AWS IAM Identity Center(AWS Single Sign-on)の利用
  • IAMユーザーのアクセスキー作成が必要な場合は次の項目を考慮する
    • ユーザー間でアクセスキーは共有しない
    • ローテーション
    • プログラムへの埋め込みをしない
• SCPによるアクセスキー作成の防止
  • AWS OrganizationsにおいてService Control Policyを適用することで対象のAWSアカウントでアクセスキーの作成を防止できる
• IAMロールの利用
  • AWSリソースにアクセスする場合、IAMロールによって付与される一時的なセキュリティ認証情報を使用することを検討
  • プログラムに埋め込まないで、プログラムを動かすEC2にIAMロールをアタッチする
• IAM Roles Anywhere
  • AWSの外部で実行されているワークロードからIAMロールを利用する
  • PKIを利用する
  • AWS Certificate ManagerのPrivate CAや外部の認証機関を利用する
  • STS経由で一時的な認証情報を発行する
• アクセスキーのローテーション
  • 定期的に変えることで被害を防止する
• AWS CLIを使用するユーザーに対するMFA認証の実施
  • MFAがfalseの場合にDenyするポリシーを利用する
• プログラムへの認証情報の組み込み防止策
  • git-secretsを使用してGitリポジトリに組み込まれることを防止
  • 開発者の環境にはこれを入れていく
• アクセスキーの監査と脅威の検知
  • キーの作成やローテーションを監査
    • EventBridgeのルールでアクセスキー作成を管理者に通知
    • ローテーション監視
      • AWS Configのマネージドルール「access-keys-rotated」を使用
      • AWS Security HubのAWS基礎セキュリティのベストプラクティスで確認
      • AWS Trusted Advisorでチェック
  • Amazon GuardDutyによるアクティビティの監視
    • 5つのデータソースを分析
      • VPC Flow LogsやCloudTrailなど
      • EC2インスタンスの認証情報漏洩の検出
        • Exfiltrationの検知が出る
  • コスト以上検出機能を使用
    • AWS Cost Anomaly Detection
    • Cost Explorerにある機能
• ログの収集
  • インシデント調査のために各種ログを収集して保存
  • 複数のAWSアカウントを運用している場合、ログ収集専用のアカウントに集約し一元管理を実施
• ログ分析
  • CloudlTrailのログを確認していく
  • どのユーザーのアクセスキーが使われているか
  • どんなAPIが実行されているか
  • 成功したか
  • IP/国は？
  • SIEMの仕組みも使うといい
• インシデント対応
  • 漏洩したアクセスキーの無効化を実施
    • IAMユーザー/IAMロール共にIAMのコンソールから無効化できる
• 質問
  • IAM Roles Anywhereは具体的にどんなケースで利用できるか
    • オンプレミスのシステムからAWSへリクエストする時に使う
    • 今までは永続的なアクセスキーを利用していたが、一時的な認証情報に置き換えられる
  • IAM Roles Anywhereはインターネット経由でのアクセスを前提としていますか？オンプレ環境のサーバからDirect Connect経由とVPCエンドポイント経由でインターネットに出ずにS3にアクセスするという場合にアクセスキーの代わりにIAM Roles Anywhereを利用したいです。
    • 確認させてください
  • IAM Roles AnywhereやCloudShellなどによって、アクセスキーが不要になるユースケースが増えているように思います。今なおアクセスキーが必要なユースケースとしてどのようなものがありますか？ 
    • 何らかの事情でアプリケーションでアクセスキーを持たないといけないことがある
    • 開発時の方針による場合もあるので、今後の開発では一時的な認証情報を利用したほうがいい
  • SIEM on AOSをつくらずに、CloudTrailのログをいい感じに分析したりできる手段はないでしょうか？
    • CloudWatch Logs InsightやAthenaなどもあるが、SIEM on Amazon OpenSearch Serviceは便利
  • OrganizationでTrailを使うと、管理アカウントのCloudwatch Logsにしか送れない（Configなどのように委任できない）のですが、他のアカウントで一元的に分析する手段はありますか？
    • 各アカウントで個別にCloudTrailのログ出力を設定していくことができる

感想

よくまとまっていい内容でしたね。全部やっていきましょう。全部！

Session2: Amazon Inspector v2 の最新アップデートの紹介とその活用方法について アマゾン ウェブ サービス ジャパン 合同会社 佐藤 航大さん

• Inspector v2の概要とアップデート紹介
  • 2021年のre:Inventで発表された
  • ソフトウェアの脆弱性やネットワーク露出をスキャンして検知する
  • EC2/ECR対応
  • もともとあったInspectorはClassicとなった
  • 変更点
    • ECRコンテナイメージスキャンサポート
    • SSM Agentによるスキャン
    • マルチアカウント管理のサポート
    • リスクスコア算出による検出結果の優先順位付け
    • スキャンできるインスタンスとイメージ数が無制限に
  • 特徴
    • シンプルで大規模な管理
      • ボタン一回で有効化
      • AWS Organizationsと統合することで複数アカウントの管理が可能
      • 自動で全てのアカウントを有効化もできる
    • 一元的に集約して可視化
      • ダッシュボードで確認
      • Criticalなものをすぐに確認できる
    • 自動検出と継続的なスキャン
      • 追加のエージェントが不要
      • イベントに応じて継続スキャンが可能
    • スコア算出による優先順位付け
      • 単にCVSSスコアを出すだけではなく、環境に合わせたスコアを出す
      • 例えばリモートでしか悪用できないCVEがインターネットに面していないEC2で発見した場合スコアが下がる
    • 対策措置のワークフロー自動化
      • EventBridgeと連携
      • Security Hubと統合
      • 後続の処理を実行できる
      • 修正されたらステータスがclosedになる
      • リスクの低いものなどをsuppressedのステータスにできる
  • アップデート
    • ECRの継続スキャンの有効期限が設定変更可能になった
      • 30日固定だったのを30日/180日/永久に変更可能
      • 頻繁にプッシュされないイメージに関しても長期にわたる脆弱性管理が可能に
• Inspector v2の応用方法
  • 応用例1: 修復アクションの自動化
    • 指定したパッケージを自動でパッチ適用できる
    • 重大な脆弱性が発見された場合にすぐに適用できる
    • CloudFormationで展開できる
  • 応用例2: 通知フローの自動化
    • AWS Security HubやAWS EventBridgeとの連携により脆弱性が検出された際に迅速に通知を行う
    • メールやSlackなど
    • Lambdaを挟んでメッセージを整えることもできる
    • フィルタリングも可能
      • Criticalのみ通知など
  • 応用例3: 脆弱性情報の可視化
    • より可視性高くカスタマイズしたい場合にS3にエクスポートして、Athena QuickSightなど
• 参考情報
  • AWS Security Hubの検出結果をS3にエクスポートするソリューションが公開された
  • こっちからやるのもあり
• Inspector Workshopの紹介
  • こちら
  • Inspector v2の使い方や連携して脆弱性管理・修復を学ぶハンズオン
  • Systems Managerからパッチ適用したり
  • まだAWS発行のアカウントでのみしか利用できない
  • すぐやりたい場合には担当営業に相談してね
• 質問
  • V2になってClassicからWindows対応やOSのCISチェックがなくなったと思っています。 それらができるClassicはそのうちなくなってしまうでしょうか？
    • AWSのドキュメントにもある通りClassicは今後縮退していく
    • 要望上げてもらうと良さそう
  • Inspectorのメール通知を受けようとEventBridgeを仕込むのですが、実験的に2017のAMIをデプロイすると1200件のメールが飛びました。。CVE9.0以上で絞ってもglibやexpatのどうでもよい検知が100件以上でます。本当に重要な通知だけを受けるためのチューニングのノウハウありますでしょうか？
    • 環境毎に異なるが、その場合はカスタマイズしていく必要がある
  • 脆弱性検知の対象となるパッケージの範囲はどこまででしょうか？インストールされているSW、MWはすべてスキャン対象となるのでしょうか？
    • Systems Managerで取得できるソフトウェア。RPMパッケージなど。
  • Cloud9の脆弱性管理をInspectorですることは可能ですか？作業環境、踏み台サーバとしてのCloud9の脆弱性管理の仕方について悩んでおり、Inspectorでできないかと考えた次第でした。
    • Cloud9で立ち上がるインスタンスもInspector v2で対応できる(2022/08/27修正)
  • inspectorだけ使えるような設定など、SSMの機能を簡単に絞ることは可能でしょうか？ SSMは高機能で バッチマネージャやRun Commandなど いろいろな機能が使えるようになりますが、 すでにansibleでサーバへ変更を適用する機能があって、SSMで使って欲しくない機能があります。
    • ユーザーに権限を与えないなどで可能
  • リスク算出について教えてください。例えば Apache2 の脆弱性で CVSSv3 の AVがNのものがあったとします。パブリックサブネットに配置されたEC2インスタンスで443/tcpを許可している場合と、プライベートサブネットEC2インスタンスで443/tcpを許可している場合ではスコアに差異が生じるのでしょうか。
    • 差が出ると考えられる
  • 実際にCVSSスコアが高い脅威が検出されている場合に、パッチ適用すべきかと思いますが、どのようにテストをすればよいか悩んでおります。何かいいアドバイスはありませんか？
    • パッチによっては再起動が必要になったりすることもあるので、同一の環境を作って動作確認をしていく
  • 「コンテキストを考慮した実用的なリスクスコア」というのは具体的にどんなイメージなのでしょうか
    • 実際のEC2の配置を加味してスコアが下がったりする
  • 環境のカバー率は、どの情報から導き出されるのでしょうか
    • EC2インスタンスの総数からInspectorが適用されている割合を出している

感想

Inspectorはv2になってすごく良くなりましたね。いろんな活用ができるようになったと思うのでバシバシ使いましょう。

まずは出てくる脆弱性をガンガン潰して行くところからですね。

Session3: スタートアップでAWS SecurityHub の運用を作っていく 株式会社justInCase Technologies 12banさん

• セキュリティとコーポレートIT両方やっている
• 会社紹介
  • 保険会社向けに保険SaaSを開発
  • 別会社でtoC向けの保険も提供
• 今回のテーマ
  • AWS Security Hub運用の仕組みづくり
  • スタートアップにおけるセキュリティの進め方
  • ※セキュリティエンジニア視点での話
  • 技術的な細かい話もなし
• 私のAWSレベル
  • 業務でもプライベートでも触ったことはあるがたまに
  • 仕事で課題解決のためにAWSが使えそうなときだけ検証して使う
  • 元インフラエンジニアなのでインフラ全般は分かっているがAWSは初心者
• AWS Security Hubとは
  • セキュリティ情報の一括管理
  • CSPMとしても使える
    • AWSの設定がポリシーに沿っているかチェックし違反していれば通知するという仕組み
    • ポリシーをどうするかがキモだが、組み込みポリシーがある
  • 組み込みポリシーがあるのはクラウドのメリット
• もしこれをデバイスセキュリティでやろうとすると
  • macOSだとJamfを使って同じような仕組みが作れた
  • 頑張って沢山コードを書いたが自分しか運用できないシステムになった
  • Security Hubは優秀
• 運用ゴール
  • AWS設定のポリシーが定まっている
  • アラート検知
  • 検知後のフロー、担当者が決まっている
  • 対応フローを関係者でテストしている
• 4つのアクション
  • AWS設定のポリシーを決める
  • ポリシーに沿って設定をしアラートを減らす
  • 運用プロセスと役割を決める
  • テストする
• AWS設定のポリシーを決める
  • ポリシーが決まっていなかった
  • セキュリティ部門としては世の中の基準をベースに決めたいがリソースが足りない
  • SREの人に知見があったのでそれをベースとした
  • セキュリティ部門にAWSに詳しい人がいなかった
  • 採用予定だったがプロジェクトには間に合わず
  • 現メンバーでキャッチアップは可能
  • AWSのセキュリティ機能をキャッチアップしていった
• アラートを減らす
  • アラート数は3000以上
  • ポリシーでアラートをフィルタしてみる
  • これは何のルール？
  • 対象のアカウントは？
  • リージョン・リソースどう違反しているのか？
  • よくわからなかった
  • 一つ一つ見ていって設定して減らしていった
  • 愚直に作業を行っていくフェーズ
  • アラートの見方を覚えていく
• 運用プロセスと役割を決める
  • 検知した後どういうプロセスでだれた何をするか決める
  • シンプルにすることを心がけた
  • 関係者はセキュリティ部門とSRE、それぞれ何するかきめた
• テストを運用する
  • 定めたプロセスをテストする
  • 課題が発見されたら整理する
• 進める上で気をつけたこと
  • セキュリティ部門の人だけでやらない、決めない
  • セキュリティの意思決定はできるが、全員がセキュリティ関係者の精神でやる
  • 積極的に開発者も巻き込んでセキュリティ意識をしてもらう
• 開発者のセキュリティ意識はそれぞれ
  • 個人個人違う
  • エンジニアだから意識高い、は通用しない
  • 一緒にセキュリティプロジェクトを進めることでセキュリティ意識、しいては文化を醸成していく
• 今回の体制
  • セキュリティは全体のリードやポリシー決定
  • SREがAWS知識や設定
  • 任せられるところを任せていく
• スタートアップのセキュリティ部門の悩み
  • プロダクトのセキュリティを開発者が担当していてセキュリティ部門から見てブラックボックスとなっている
  • 統制が取れていない状態
  • このプロジェクトのようにセキュリティ部門が企画、プロジェクト化して、開発者と一緒にやっていける
• まとめ
  • AWS Security Hubをうまく使うことでAWSのセキュリティレベルを保つことができる
  • 開発者を巻き込んで進めていくのがいい
  • それがセキュリティ意識向上、しいては文化醸成につながっていくのではないか
• 質問
  • SecurityHubのセキュリティ基準の部分ですが、本番運用前までにはなるべく１００％に近づけるような運用をしています。本番後、ふと気づいたときには相当下がっているのですが、定期的な脆弱性管理として、何か工夫、アドバイスはありますか？
    • 下がっているということはポリシーに違反しているということ
    • Slack通知してすぐに気づいて対応するなど、対応プロセスを作っておくことで大きく下がることを防げるのでは
  • 社内ポリシーの決め方はそもそもどのようなアプローチで行われましたか？それをSecurityHubのアラート内容とマッピングするような形で行われたのでしょうか？
    • 会社によって違うと思うが、今回は少ない時間でやらなければいけなかったので世の中のガイドラインを使いたかったが今回は知見のある人に頼った
  • 運用プロセス内で、セキュリティ担当とSRE担当とでの線引はどのようにされていますか？
    • セキュリティ担当は検知した後に、それをインシデントと捉えてクローズされるまで管理する
    • 実際の対応はSREで、ポリシーの例外にするなどの判断はセキュリティ側
  • GCPやAzureなどとも連携して、GCPやAzure側の設定がポリシーに沿っているか確認することはできますでしょうか？
    • マルチクラウド対応CSPMならできるのでは
  • 私の社内体制の話となりますが、実際にSecurityHubを触っている運用担当者と、社内のセキュリティ担当者（意思決定者）が分かれている場合、SecurityHubのコンソール画面をセキュリティ担当者が見れるわけではないので、意思決定していくのが大変でした。何かコミュニケーションのコツがあれば教えてください！
    • セキュリティ担当もAWSの画面を見えたのでそれをベースに具体的な話をしている
    • それができる方が早い
  • Security Hubの担当者のポリシーでセキュリティが担保できていると判断した根拠とコツを教えてください という質問がおくれてやってきたので、もし文章で回答いただけたら
    • 手法はいくつかあると思いますが思いつくのは2つです。ガイドライン（PCI DSSやCISなど）に沿うのであれば、そのガイドラインをもとにポリシーを作成して、 ポリシーにどれだけ遵守しているかという根拠で見ていくのが早いと思います。また別の方法として会社のリスクアセスメントやAWSのリスクアセスメントなどの結果と合わせて十分にリスクが低減されているかを評価して根拠とする方法もあると思います。

感想

まさにそうだなー、うんうんと思いながら聞いていました。一緒にやって文化醸成頑張らないとですね。

Session4: 脆弱性管理の自動化を実現するDynatrace Application Securityの紹介 Dynatrace 角田 勝義さん

• Dynatraceは監視周りで12年リーダーポジション
• モダンなITオペレーションのためのオールインワンソリューション
• 今回アプリケーションセキュリティがリリースされた
• Dynatrace Application Security
  • セキュリティと言ってもいろんな対象がある
    • ユーザー
    • ネットワーク
    • ホスト
    • アプリケーション
    • データ
    • クラウド
    • などなど
  • アプリケーションの脆弱性管理から対応
• 脆弱性コードの実行とそのリスクを理解
  • ライブラリがアプリケーションで使われているのか
  • インターネットからアクセスできるか
  • DBへアクセスしているか
  • どのエンティティに影響があるか
  • exploitコードは公開されているか
  • Davis AIがリスクレベルを判断してくれる
• 優位性
  • 自動的かつ継続的なセキュリティ対策の実現
    • 新たな脅威も自動で対応
    • 定期的なスキャンは不要
  • 脆弱性対応にかかる時間の削減
    • トランザクションデータから動作環境のトポロジーを作成
    • 正確なリスクアセスメントが可能
    • 脆弱なエンティティの洗い出し
  • 導入の容易性と迅速化
    • 単一のエージェントの導入のみでインフラからアプリケーションに加えてセキュリティ監視を実現
    • アプリケーションコードやコンフィグレーションの変更は一切不要
• Log4Shellの脆弱性を即座に検出、リスクレベルを把握
  • 脆弱性のデータベースとしてSnykを利用
  • 12月10日にSnykのDBに情報が乗ったら5分後にはアクセス情報やスコア付けをできていた実績がある
• デモ
  • AWS上の多数のホストとプロセスから60個の脆弱性のあるプロセスを特定している
  • プロセス単位で出せるのは特徴
  • コンテナやFargateなどを利用しているとホスト単位ではなくなるため
  • ダッシュボード
    • 概要画面
    • 5つのリスクのある脆弱性が確認できる
    • 時系列でリスクレベルの遷移が確認できる
    • 重大な影響を受けているプロセスとしてSpringBootを検出している
  • サードパーティの脆弱性
    • サードパーティのライブラリでLog4Shellのような脆弱性があった場合
    • Davisセキュリティスコアが付けられる
    • 9以上がクリティカルと判断される
    • インターネットにつながっているとか、DBに実際にアクセスしているとかが調査されていて、スコアに反映されている
    • 脆弱性の詳細はSnykと連携して確認できる
    • ECRのイメージも確認している
    • イメージ側をスキャンしているわけではなく、それが動いているところについて情報が出る
• まとめ
  • APM & Observabilityの分野をリードしている
  • インフラからアプリケーション、フロントエンドからバックエンドまでフルスタックでの監視を実現するソフトウェアインテリジェントプラットフォーム
• 2週間のフリートライアルをAWSのマーケットプレイスからリクエストできる
  • Application Security機能は別途営業担当社に連絡する
• 質問
  • 本日、InspectorやSecurityHubの話がありましたが、AWSのどの機能と競合するのでしょうか？競合する機能があれば、Dynatraceの優位性を伺いたいです。
    • 特にInspectorとは競合しそう
    • 優位性はAWSに限らずオンプレミスも含めて見ることができる
  • Dynatraceのアプリケーションセキュリティの料金体系ですが、導入するAgent数に比例する形でしょうか。他にオプションのサブスクリプションなどありますか？
    • 管理対象のメモリサイズに依存する
  • Dynatraceで攻撃クエリを遮断することは可能でしょうか？
    • 機能としてはある
  • AIを活用しているとのことでしたが、こちらはAgentから情報を収集して学習する仕組みでしょうか。
    • いわゆる機械学習とはちがう
    • Davisが皆さんのチームにジョインしてチェックしているイメージ
  • イメージとしてはRASPの領域だと思いますが、他社のRASP製品との違いや競合優位性はどういったところでしょうか？（One Agent以外で）
    • トポロジーをみてリスクアセスメントできる
  • オンプレのサーバーはエージェントが導入できないのでしょうか？
    • オンプレミスでも導入可能
  • log4jは依存関係の深いところで利用されていると思いますが、Javaのライブラリの依存関係の深いところの脆弱性も検知できますでしょうか？
    • できる
    • 実際にどのクラスがロードされたかなど確認している

感想

統合的に色んなものをまとめて管理できるのは面白そうですね。

Session5: AWS Step Functionsでオンボーディング・バクラク LayerX Kengo Suzuki ( @ken5scal )さん

• 入退社のオンボーディングをStepFunctionsで対応した話
• 請求書処理をするバクラクなどを作っている
• 効率化色々やったよという話のセキュリティサイドの話
• サービスが半年で企業数10倍、KPIである処理請求書数20倍
  • ちゃんと開発・マーケ・セールスなど全方位必要
  • 採用に力を入れる
  • 社員数6倍弱
  • 素手だと大変なので自動化した
• 45分/人 * N人だったのが人数関係なく10分で終わるようになった
• 解決
  • フローを整理
  • 手順書に起こす
  • StepFunctionsで自動化
  • LambdaだけではなくTerraformやGitHub Actionも連携
  • 改善もできるし試して直して行ける
• 自動化によってえられるメリット
  • 既存の作業の延長上のメリット
    • 再現性が強まる
    • エビデンスの取得がより容易になる
    • プログラム側に問題があってもマニュアル作業と互換性がある
  • 新しいメリット
    • 人間が得意なことに集中できる
• 自動化によるリスクを考慮した技術選定
  • SSMJPでもそんな発表があった
  • リスクを考える必要がある
• そもそもオンボーディングとは
  • 国際標準の呼び方ではない
  • ISOとしてはデジタルアイデンティティの登録はenrolment
  • 新しいIDの登場によってそれを登録する
  • オペレーションそのものが高い権限を要する
    • 正しい入社情報に基づいて登録
    • 初期パスワードを正しいところに送る
    • 権限を付与する
  • 自動化のスコープ
    • 人間の判断をはさみたい
    • トラストアンカーはCTO室にしたい
    • 最近では人事DBを使うものもあるが、人事DBってセキュアなの？となる
    • 人事DBがトラストアンカーになるのでよくない
    • 全ての信頼を依拠できない
  • 作業を実施する権限の分離
    • 詳細なアクセス制御を実装・切替可能
      • 機能
        • 実行、暗号化、ログ、デリバリ、デバッグ等
        • ヘルプデスクは何ができるのか
          • 復号はできないように
  • DFIR・追跡性・責任説明
    • 平たく言うとCSFに対応する運用を実装可能でないと困る
      • 人間による説明責任を果たしたい
      • 入力されたデータの責任はCTO室が持つ
      • 実行タスクの状況だけでなく、データ入出力・Vaultの入出力などなど
  • 高い独自要件と変更容易性
    • オンボーディングに国際標準はない
      • 独自仕様にせざるをえない
    • 変更が容易である必要がある
    • 兼務なのでめんどくさくない変更フローが重要
  • コストは抑えたい
    • 財務的にはコストセンター
      • 業務内容に合わせた経理的な仕訳がそうなるだけなので気にする必要はない
      • だからこそ安くしたい
• のでAWS Step Functionsに全のっかり
• ここが嬉しい
  • 独自ドメイン要件に合わせた自作のスクリプト・プログラムをローコストで実行可能
  • Lambda, DynamoDBといった従量課金系
  • DBへのアクセスを実装しなくて良い
  • 利用者数に比例しない
  • 暗号化・復号、Vault、権限管理、アプリ実行ログ、監査ログ全てを利用可能(非機能要件の実装)
  • CI/CD化できる(キーレスで)
• ここが難しかった(技術選定の問題)
  • リトライ処理に合わせたWorkflowの単位
    • Try Catchしてもstate管理をするのがなかなかめんどくさい
  • ローカルでの開発
    • Localstackつかってもぶっちゃけめんどくさい(特にセットアップ)
    • Activityでごちゃごちゃ頑張るより、SDKでAPI叩いたほうが動くものをぱっと作りやすいというのもある
  • Yaml管理しんどい
    • Terraformでやっているから。CDKにしたい
• こうなると嬉しい
  • ECSみたく環境変数をSecrets Manager Arn指定で指定したい(Lambdaも含む)
    • オペレーションからInput/Outputが見えてしまう
  • Cognito発行のID Tokenでaud指定できるようにしてほしい
    • マシン2マシン認証用
• Step Functionsはいいぞ
• 質問
  • LambdaやDynamoDBが従量課金とのことですが、作ったシステム全体で毎月いくらくらいコストがかかってますか？
    • コストアノマリ検知されていないのでそんなに上がっていないはず
  • AWS製品ではないのですが、サードパーティ製品でLamdaを保護するCWPP製品もあるかと思います。そのようなセキュリティ機能を実装するような検討はされていますでしょうか？
    • 今後は検討すると思う
    • リスクアセスメントを進めていく中での優先順位で対応
  • IaCスキャンは実装していますか？
    • GHAでTrivyを動かしている
  • Azure（ Logic Apps）やGoogle Cloud（Workflow）がある中、AWS（Step Functions）を採用した決めてはなんでしょうか？
    • 単純にどのくらい習熟度があるか
    • もしAzureやGoogleのほうが知識があればそちらを使っていた

感想

いい自動化実装の事例ですね。どこにトラストアンカーを置くのは非常に大事な話で参考になりました。

Session6: AWS Organizations連携サービスの罠 NTTデータ 奥村 康晃さん

• 背景
  • AWS Organizationsが一般的に利用されることが多くなり、それに伴い連携可能なAWSサービスを使いたいという相談が増えた
  • あまり検討をされずに使い始めてしまうと後から設計変更を余儀なくされたり使われなくなったいrと不幸なことが起きる
  • そういったことを未然に防ぎたい
• AWS Organizations連携サービスとは
  • マルチアカウントの情報を集約管理したり一括制御できるサービス郡
  • 30以上ある
  • 実運用上ハマりやすいポイントがある
  • セキュリティ関連サービスについて話す
• AWS Config
  • Organizationsと連携できることは
  • 組織のメンバーアカウントのAWS Configで記録しているAWSリソース構成情報をまとめて表示可能
  • Configルールの評価結果をまとめて表示可能
  • 罠
    • 自動で全てのメンバーアカウントのAWS Configを有効化できない
    • 一括のルール配布もできない
    • それぞれ別の仕組みが必要
  • 対応策
    • AWS CloudFormation StackSetsがおすすめ
      • 1つのテンプレートで複数のAWSアカウントにスタックを作成できる
    • StackSetsで有効化も一括配布もできる
  • ちなみにCloudTrailはOrganizations連携で一括有効化できる
• AWS Security Hub
  • 連携すると検査結果をまとめて表示したり一括で有効化できる
  • 罠
    • 統合可能サービスと連携させるには同一のAWSアカウントを委任管理者として設定しないとすべての機能を利用できない場合がある
    • Organizations連携するときはデフォルトで管理アカウントに集約される
    • 管理アカウントは請求情報などのセンシティブなものがあるため多くの機能を持たせないのがベストプラクティス
    • 代わりにメンバーアカウントに委任するために委任管理者アカウントを指定できるものがある
    • 例えばSecurity HubとDetectiveを別管理していると、Security HubからDetectiveの詳細画面に移動できない場合がある
    • 特にGuardDutyとDetectiveは気にする必要がある
    • 公式でもセキュリティサービスは同一アカウントにするべきとアナウンスが出ているので揃えよう
  • ちなみにSecurity HubはConfigが必要
    • 芋づる式に検討するものが増えるのがOrganizations連携サービス
• Amazon Detective
  • Organizationsと連携すると各メンバーアカウントの検知を集約、自動で一括有効化
  • 罠
    • Detective自体がGuardDutyの有効化後48時間経過しないとDetectiveを有効化できない
    • 48時間経過しないと委任管理者を指定できない
• IAM(組織アクティビティ)
  • 管理アカウントだけで使える
  • 最後に利用したAWSアカウントを把握することができる
  • IAMアクセスアナライザーの組織版みたいなもの
  • 一見良さそうに見えるがかなり粗い粒度でしか見えない
    • アクションまでみれない
    • 操作者はアカウントまででIAMレベルで見えない
    • SCPで許可されているサービスのみでDenyされているサービスへのアクセスは検知できない
  • 参考
    • 他にも管理アカウントでしか利用できないOrganizations連携サービスもいろいろある
    • SCPで制御もできない
    • IAMでの制御をしっかりやらないといけない
• まとめ
  • 罠を紹介
    • Config: 一括有効化やルール配布の仕組みを検討
    • Security Hub: 同一AWSアカウントを委任管理者に設定
    • Detective: 48時間に気をつける
    • IAM(組織アクティビティ)粗いので注意
  • 現時点では注意ポイントはいくつかあるもののマルチアカウント環境を集中管理するためのメリットは大きい
• 質問
  • なぜOrganizationsを使うことになったのでしょうか？使う前と後で改善された点があれば伺いたいです。
    • アカウント数がすごくたくさんあるため
    • SCPによるシンプルなアクセス制御やサービス連携などいろいろいい
  • Organizationsをちゃんと使わないとやめることになるとお話がありましたが、奥村さんが途中で使うのをやめなかったのはなぜでしょうか？
    • 数が多いので使わなければ生きていけない
  • セキュリティではないのですが、コスト管理の観点からOrganizationsを使うメリットはありますでしょうか？
    • 請求情報を集約できる
    • RIなどをまとめて適用できる
  • 最初のセッションで、SCPを使ってアクセスキー発行禁止する例がありましたが、SCPの統制はどのくらい厳しくやっていますか？
    • 組織内では2層でやっているのでそんなに多くはやっていない
    • Organizationsから抜けられないようにするなど
    • 細かいのは別組織で管理している
  • SCPのテストは別環境で実施されていますでしょうか？また、SCPのポリシー管理やデリバリー方法など、教えていただくことは可能でしょうか。
    • 別環境もあるしOU分けるのもあり、それぞれ使える
    • 管理は難しいが別の場所に出したりもしている
    • Terraformを使ったりはまだできていない
  • OUの切り方で工夫される点はありますか？
    • 禁止したい操作の塊で分けていく
  • Stack Setsのリソース（Configなど）について、メンバーアカウント側に更新や削除させない対策をとっていますか？？
    • SCPでコントロールしている
    • タグ付けや命名規則で縛る
  • AWS SSOを利用するとIAMを用いないでログインが可能かと思いSSOもOraganizationsを使うメリットの一つだと思うのですが、SSOを導入するケースとIAMのスイッチロールを使うケースはマルチアカウント管理をする上でどちらの方は多いでしょうか？
    • 1つの組織で閉じられる場合はAWS SSOを使う場合が多い
    • 組織によっては複数AWS Organizationsを使うのでその場合はJumpアカウントも使う

感想

あるあるーと思いました。細かいところは色々あるので、検討するときは結構ガッツリ触りながら検証しましょう。あとはAWS Control Towerも検討しましょうね。

Session7: [クラウドZoom相談] 当日のslido & ドアキで受付けた質問に回答する枠 Security-JAWS運営メンバー

• Amazon Inspectorはセキュリティ診断のインフラ足り得るのか
  • 脆弱性管理のポジションなので、診断にはならない
• スキャン結果の脆弱性（CVE）を実際のシステム構成情報と照合して、脅威度判定するような脆弱性管理ツールは技術的に可能なものでしょうか？＊例えばNW構成やWAF等の別レイヤでアタックベクター自体をブロックしていれば、その脆弱性は実質的に存在しないので低リスク評価されて欲しい。脆弱性ツールを導入して対応すべきアラートが増えるのは仕方ないと言えますが、運用コストの増大や開発効率の低下も避けるべき事象だと認識しているため、検知されるリスク（アラート）に確実に対処していく仕組みに関心があります。
  • Inspector v2がまさにそれ
  • EC2の配置でスコアを変更してくれるのでありがたい
  • ただWAFについては判定できない
  • WAFについてはルールの中身まで判断材料にしないといけないので自動で評価する仕組みというのは難しそう
• Securityhubを利用していますが、絞り込み等使いにくく、slackへの通知ように集約と正規化する用途がいいのでは?と思い始めています。ベストプラクティスはどんなんでしょう?
  • 絞り込みをしていくよりは、出てくるものをやるやらないとポリシーを決めていくところをまずやるとよさそう
  • そのポリシーの決め方は下記ブログの後半を参考にしてください

• セキュリティエンジニアの守備範囲はどこらへんが一般的でしょうか。ネットワークだけ、アプリだけ、、等。
  • 全部
  • セキュリティは全てに関係する
  • 分業することはあるので組織の状況に応じて役割分担は変わる
  • 全員でセキュリティをやりましょう
  • この質問がセキュリティエンジニアを目指している、という視点であれば好きなもの、得意なものからキャッチアップしていくとよさそう

さいごに

今回もいろんなためになる話がありましたね。記事だけ読んだ方は是非動画も見てください！

いろんなやった体験も誰かのナレッジになりますから、ぜひ「僕らはこうだったよ」という話も含めて登壇を募集しています！